Conversation
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📝 WalkthroughWalkthroughAdds VS Code Git extension API integration: new TypeScript typings, Changes
Sequence DiagramsequenceDiagram
participant Ext as Extension
participant GitExt as VSCode Git Extension
participant Repo as Repository
participant Deco as Decoration/Status Manager
Ext->>GitExt: request getAPI(1)
alt Git API available
GitExt-->>Ext: Git API
Ext->>Ext: registerGitStateWatchers(context)
Git API->>Ext: onDidOpenRepository / repository.state.onDidChange
Ext->>Deco: refresh decorations & update status bar
Repo->>Ext: state.onDidChange events
Ext->>Deco: refresh decorations & update status bar
else Git API unavailable
GitExt-->>Ext: unavailable -> log warning, do not register watchers
Ext->>Deco: rely on editor/file events only
end
Estimated Code Review Effort🎯 3 (Moderate) | ⏱️ ~22 minutes Poem
🚥 Pre-merge checks | ✅ 5 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@src/extension.ts`:
- Around line 137-146: The function registerGitStateWatchers currently returns
true immediately when extension.activate() is fired asynchronously; change it so
that when the Git extension is not active you return false (so the caller will
create the .git/index fallback) and attach a .catch() to the promise from
extension.activate() to handle activation failure and log or fall back;
specifically, update the branch where extension.isActive is false to call
extension.activate().then(exports => onGitReady(exports as GitExtensionExports |
undefined)).catch(err => { /* handle/log and ensure fallback remains */ }) and
return false instead of true, leaving the existing immediate-return-true only
for the extension.isActive path so callers can rely on the boolean to decide
whether to set up the filesystem fallback.
🧹 Nitpick comments (1)
src/extension.ts (1)
165-165: Floating promise: prefix withvoidfor consistency.Other call sites (lines 111, 125, 312) use
void updateStatusBar()to explicitly discard the promise. This call should match.- updateStatusBar(); + void updateStatusBar();
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Avni2000
force-pushed
the
status-bar-updates
branch
from
dbd89ce to
4f5eaba
Compare
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/extension.ts (1)
304-316:⚠️ Potential issue | 🟡 MinorFloating promises from
updateStatusBar()in file-watcher callbacks.Lines 306, 310, and 314 call
updateStatusBar()withoutvoidor.catch(), creating unhandled-promise-rejection risk ifgitIntegration.isUnmergedFilethrows. The Git-watcher callbacks on lines 115 and 325 already usevoid updateStatusBar()correctly — apply the same pattern here (and on line 170) for consistency.Proposed fix
fileWatcher.onDidChange(uri => { decorationChangeEmitter.fire(uri); - updateStatusBar(); + void updateStatusBar(); }), fileWatcher.onDidCreate(uri => { decorationChangeEmitter.fire(uri); - updateStatusBar(); + void updateStatusBar(); }), fileWatcher.onDidDelete(uri => { decorationChangeEmitter.fire(uri); - updateStatusBar(); + void updateStatusBar(); })And on line 170:
- updateStatusBar(); + void updateStatusBar();
🧹 Nitpick comments (2)
src/extension.ts (2)
318-328: Dual watchers active when deferred Git activation succeeds.When
registerGitStateWatchersreturnsfalse(extension not yet active), the fallback.git/indexwatcher is created. If the Git extension later activates successfully,onGitReadywill register the API-based watchers too — both mechanisms then fire simultaneously, causing redundant decoration refreshes andupdateStatusBarcalls.This is not harmful but worth being aware of. If you want to tighten it up later, you could store the fallback watcher's
Disposableand dispose it insideonGitReadyonce the API watchers are confirmed.
35-50: Consider using the VS Code Git extension's official type definitions.The VS Code Git extension ships type definitions (
git.d.ts) available in the VS Code repository. The recommended approach is to vendor this file into your extension (e.g.,src/typings/git.d.ts) and import the canonical types:import type { GitExtension, API as GitAPI } from './typings/git';Also add
"extensionDependencies": ["vscode.git"]topackage.jsonto ensure activation order. This approach keeps types in sync with API changes automatically and avoids manual interface maintenance.The current hand-rolled interfaces are sufficient for your use case, but adopting the shipped types aligns with VS Code extension best practices.
1 participant
Summary by CodeRabbit
New Features
Improvements